NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/932

Internet Message Format | 1996-08-06 | 4.8 KB

Path: dawn.mmm.com!news
From: [e-mail] (Kevin J Hopps)
Newsgroups: comp.lang.c++
Subject: Re: Exceptions vs. assertions
Date: 8 Jan 1996 14:34:27 GMT
Organization: 3M - St. Paul, MN  55144-1000 US
Message-ID: <4cra1j$[e-mail]>
References: <4al1hn$[e-mail]> <4bpt9b$[e-mail]> <4ch1is$[e-mail]>
Reply-To: [e-mail]
X-Newsreader: TIN [version 1.2 PL2]

Rob Stewart ([e-mail]) wrote:
> Exceptions aren't free.  Typically, each try block you code
> causes a performance hit, so limit the number of try blocks
> you use the best you can.  When you throw an exception, much
> occurs behind the scenes.  Throwing an exception is more
> expensive (in performance terms) than a simply function
> return.  If you can throw an exception for several different
> reasons, you may still need to decode the reason in the catch
> block, so that isn't any different from decoding an error code
> returned by a function.

The implementation of exceptions is very system dependent.  It
is dangerous to make general assumptions based on one vendor's
implementation of them.

People have sent me results of tests run on a dozen or so
compilers.  On average, when no errors occured, code that
contained try blocks performed at 95% of the level of equivalent
code using return values.  Many try-blocks can be avoided by
using resource-releasing classes.  To me, this makes the code
easier to read.  I avoid them for this reason, but not because
of performance.

> As a result, you should limit your use of exceptions.  Don't
> be afraid of them, but don't throw them when a simple result
> code would suffice, unless the sort of error you're reporting
> is quite likely going to unwind a great deal of functions
> calls from the stack.  Such an error is probably of the
> "catastrophic" variety anyway.

Performance is a very important consideration when errors *do*
occur.  The same tests showed that, on average, the exception
version of code performed at only 30-40% of the level of
equivalent return value code (2-3 times as slow) when errors
did occur.

When deciding how to report an error, I consider not so much
whether a return code would suffice, but how likely it is
that the condition I'm reporting will actually occur.

For any given function, this can be very dependent on the
context of its use.  For example, consider the function
    FileHandle openFile(const char* name);
In the context of "saving to disk" it is probably an [unlikely]
error if this occurs.  In the context of "reading optional
resources" the file might be missing a significant portion of
the time.  Because throwing exceptions is expensive in terms
of performance, I would probably use a return value if the
condition to be reported is "normal" in a significant portion
of the function's uses.

> For example, a disk full condition is likely to unwind
> numerous functions back to some common point at which the
> program notifies the user of the condition and asks how to
> proceed.  The program may allow the user to repeat the action
> (hopefully after the user deleted some files from the full
> volume).  You could return disk full as an error code and pass
> it back the call chain until you reach the right point in the
> code to prompt the user.  Since there aren't likely to be many
> functions in the call stack that can handle it, "disk full" is
> a good candidate for an exception.

Whether exceptions or return values are used to report an error,
it needs to be propagated to the code that actually handles it.
How the error is handled has little to do with how it is reported.
Good candidates for exceptions are situations that do not occur
under normal circumstances.  The number of intervening functions
in the call stack seems less important a factor in the decision.

However, error propagation with return values is a place where
bugs are introduced.  Failing to propagate an error is much harder
to do when exceptions are used.  In this way, depth of the call
stack may be a factor in the decision on how to report an error.

> On the other hand, a more temporary failure might not be
> considered catastrophic, and could be handled closer to the
> troubled function call.  It really is subjective.  You can't
> even say, "I'm not sure what's a bad use of exceptions, but
> I'll know it when I see it."

I still think that the seriousness of the error and the placement
of the error handler are determined independently of the error
reporting mechanism.
--
Kevin J. Hopps                  e-mail: [e-mail]
3M Company                      phone:  [phone]
3M Center, Bldg. 235-2D-57      fax:    [phone]
St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.
    But 3M speaks for me -- I did not write the following line:

Opinions expressed herein are my own and may not represent those of 3M.